Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Provide abstract base class for a string object #333

Closed
wants to merge 1 commit into from
Closed

Provide abstract base class for a string object #333

wants to merge 1 commit into from

Conversation

awvwgk
Copy link
Member

@awvwgk awvwgk commented Mar 11, 2021 •
edited
Loading

This patch implements an abstract base class (ABC) for an extendible string class (not to be confused with the non-extendible string type). The implementation also shows the full insanity of object oriented string handling in Fortran required to just support the intrinsic functionality and sheds some light on the current state of compilers implementing class inheritance.

Goals of this PR

  • provide full compatibility with the functional string_type
  • provide overloaded interfaces in the base class to define all character intrinsic functions for both character scalars and functional strings
  • add preliminary specs on the public API of the abstract base class
  • add developer API documentation for all available type bound procedures
  • add tests to check a minimal implementation of a string class

Design strategy

  • provide an ABC rather than an actual class to handle extendible string objects
  • rely on the string_type as return value rather than returning polymorphic string objects
  • stdlib_string_class defines and exports overloaded interfaces for the ABC, which should be reexported in implementations to provide intrinsic functionality (still requires explicit import)
  • operators and UDDTIO are type-bound rather than overloaded interfaces (easier to import)
  • string_class can be created by assignment from character values, string types or string objects

Additional resources

I prepared the stdlib_string_class module in awvwgk/stdlib_string as fpm project. The specs are available at https://awvwgk.github.io/stdlib_string. The projects also includes a version of ftlString and StringiFor based on the string_class proposed here.

@awvwgk awvwgk added the topic: utilities containers, strings, files, OS/environment integration, unit testing, assertions, logging, ... label Mar 11, 2021
@awvwgk
Provide abstract base class for a string object
d3752b0 
- provide full compatibility with the string_type
- provide overloaded interfaces in the base class to define all
  character intrinsic functions for both character scalars
  and functional strings
- add preliminary specs on the public API (not developer API)
  of the abstract base class
- add tests to check a minimal implementation of a string class
This was referenced Mar 11, 2021
Merged
Open
@milancurcic
Copy link
Member

Does this add functionality relative to the string_type or is it just an API difference?

@awvwgk
Copy link
Member Author

awvwgk commented Mar 11, 2021

As with the string_type patch, I'm trying to not add any functionality with this patch yet, but provide a scaffold with the already existing functionality to build upon later. The main difference between string_type and types inheriting from string_class are that the latter are extendible. Also, due to the fact that they are class polymorphic, function pointers are resolved at runtime rather than at compile time.

@milancurcic
Copy link
Member

Okay, thanks. I think it warrants a broader discussion then. Should stdlib offer:

  1. Only the string type
  2. Only the abstract string class
  3. Both
  4. Something else

My current opinion is that we should aim to minimize overlapping functionality. So, is a string_class needed? It seems to me the answer is yes only if you want to extend it, and it's not clear that it would be strongly desired feature. But if it is, then we should ask, should string_class replace string_type or be added to it. Having both is of course an option, but I think it needs to be justified, i.e. there are clear and non-overlapping use cases for both.

@awvwgk
Copy link
Member Author

awvwgk commented Mar 11, 2021 •
edited
Loading

Yes I would be happy to discuss this in more detail. Parts of the issues regarding functional vs object-oriented string types were discussed in #69, but we should start a separate issue regarding this (see #334).

@awvwgk awvwgk added the wontfix This will not be worked on label Mar 27, 2021
@awvwgk
Copy link
Member Author

awvwgk commented Mar 27, 2021

I'm going to mark this patch as wontfix, but will leave it around for now. If anyone is interested in continuing it, let me know or just feel free to adopt it for your project.

@ivan-pi ivan-pi mentioned this pull request Mar 30, 2021
Open
@awvwgk
Copy link
Member Author

awvwgk commented Jun 27, 2021

Since I'm not planning to continue working on this, I'm going to close this PR.

This patch can be resurrected from d3752b0 if needed.

@awvwgk awvwgk closed this Jun 27, 2021
@awvwgk awvwgk deleted the string-class branch June 27, 2021 14:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
topic: utilities containers, strings, files, OS/environment integration, unit testing, assertions, logging, ... wontfix This will not be worked on
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@awvwgk @milancurcic